The feature of default boost value could be more than essential for this library. Perhaps I can remove it if it is not desirable

I agree - I think the boost value should always be supplied by the caller.

FYI we do already have a higher-level boost mechanism here:

It would be helpful to add to the docs a short example of when one would prefer to use the boost_query() method instead of the field_boosts parameter in parse_query(). Perhaps when building up a chain from a Query type that is not supported by the query parser language?

I agree - I think the boost value should always be supplied by the caller.

FYI we do already have a higher-level boost mechanism here:

tantivy-py/tests/tantivy_test.py

Line 98 in deb88cc

query = ram_index.parse_query("winter", field_boosts={"title": 2.3})

It would be helpful to add to the docs a short example of when one would prefer to use the boost_query() method instead of the field_boosts parameter in parse_query(). Perhaps when building up a chain from a Query type that is not supported by the query parser language?

I have resolved the conflicts and updated the boost query not to have default value.

There should be two more tests:

• ✅ Boost value 0 will return the 0 score
• ❌ Error if no boost value is supplied

For the documentation, I am thinking should we add a new section under Building and Executing Queries, perhaps we should rename Building and Executing Queries section to something like Quickstart with QueryParser?

Currently we have a lot of implemented methods regarding the issue #20 and I think we should have a proper documentation for parameters accepted and usecases.

Currently we have a lot of implemented methods regarding the issue #20 and I think we should have a proper documentation for parameters accepted and usecases.

yep agree 💯

should we add a new section under Building and Executing Queries

Your suggestions lead me in the direction of:

• we rename the existing Building and Executing Queries to Building and Executing Queries with the Query Parser
• add a new tutorial called Building and Executing Queries with the Query Objects, where we can add tutorial content using the new objects.

What do you think?

We can merge this PR first anyway, and do such docs in a different PR.